Skip to content

Lightning Address activation: honest timeout and a named wait - #160

Draft
BullishNode wants to merge 2 commits into
getpaid-2-61-la-advanced-settingsfrom
getpaid-2-62-activation-feedback
Draft

Lightning Address activation: honest timeout and a named wait#160
BullishNode wants to merge 2 commits into
getpaid-2-61-la-advanced-settingsfrom
getpaid-2-62-activation-feedback

Conversation

@BullishNode

Copy link
Copy Markdown
Owner

Owner QA findings from the live walkthrough, Lightning Address activation feedback. Stacked on the advanced-settings PR.

  • A claim timeout no longer reads "status unknown." A registration whose request got no answer (timeout/network — tonight's real case was a 15s nginx 499 while the server chewed a 24s watcher scan, bullnym#282) now says the server did not answer and nothing was claimed, with a direct retry. A genuinely uncertain outcome (the server answered unintelligibly) keeps the cautious copy. If a "failed" claim actually landed, the existing NymAlreadyAssigned reconciliation still resolves it on retry.
  • The wait between activation success and the fiat chooser is now named and consistent. It's a real server read (the product's current payout configuration — kept, because skipping it would show stale state for re-activated products), but it rendered as the app's only bare spinner. Now the standard shimmer skeleton plus "Checking your current payout settings with Bull Bitcoin…".

Gates: analyze clean, lightning_address 102 + fiat_settlement 45 green, full suite 2360 on the stack tip.

…tus unknown"

A claim that timed out — tonight's case, where the server took longer than ~15s
and nginx logged the client disconnect — surfaced as "Status Unknown:
registration may have succeeded. Check status before trying again." That reads as
though the app knows something it does not: no answer came back at all.

Map a timeout or an unreachable server to their own outcome, stating that the
server did not answer, that nothing was claimed, and offering a retry of the
claim itself rather than a status re-read. A garbled answer stays genuinely
uncertain, which is what that surface was for. If the claim did reach the server,
the retry still lands correctly: the NymAlreadyAssigned reconciliation already
handles that.
After a successful activation the app pushes this editor, which cannot draw
anything until the server answers with the product's current payout
configuration. That read was covered by a bare CircularProgressIndicator — the
only one in this flow, and unlike the shimmer skeleton every other Get Paid
screen uses — with nothing said about what was being waited for. On a slow server
that reads as a hang between the success screen and the chooser.

Use the same skeleton the Lightning Address, Donation Page and Point of Sale
screens use while they read their own server state, and state what the wait is.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants